fix: sort epInfos to process InfraNIC first before EndpointCreate#4421
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR ensures the CNI plugin processes InfraNIC endpoints before other NIC types during ADD, avoiding incorrect network binding in stateless mode that can later cause endpoint creation to fail with a missing host interface.
Changes:
- Sort
epInfossoInfraNIC(and legacy emptyNICType) are processed first before callingEndpointCreate. - Add a Linux unit test to validate the intended ordering behavior.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| cni/network/network.go | Sorts epInfos prior to EndpointCreate so InfraNIC is handled first in stateless mode. |
| cni/network/network_linux_test.go | Adds a unit test covering the InfraNIC-first ordering logic. |
Move the epInfos sort from network.EndpointCreate to the CNI plugin layer (cni/network/network.go) after the createEpInfo loop. In stateless mode, ExternalInterfaces is empty on every ADD so whichever NIC is processed first determines which interface the network gets bound to. If DelegatedVMNIC wins the race, SecondaryEndpointClient moves its interface into the pod namespace, then TransparentEndpointClient fails with "no such network interface". Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
behzad-mir
force-pushed
the
fix/sort-epinfos-infra-first
branch
from
fb45141 to
c665385
Compare
QxBytes
reviewed
May 29, 2026
Address PR review comments: - Extract isInfraOrLegacyNICType() helper function to deduplicate the repeated NICType == InfraNIC || NICType == "" checks - Replace TestSortEpInfosInfraNICFirst with TestAddSortsInfraNICFirst that tests through the plugin.Add() flow, verifying InfraNIC is created first by recording endpoint creation order via mock callback - Use the helper in both the sort comparator and the Delete path Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Address PR review comments: - Extract sortInfraNICFirst() to encapsulate the sort logic that ensures InfraNIC is always processed before other NIC types - Extract isInfraOrLegacyNICType() helper to deduplicate the repeated NICType == InfraNIC || NICType == "" checks - Replace complex integration test with simple unit test for sortInfraNICFirst covering multiple NIC type orderings - Use the helper in both the sort and the Delete path Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
Author
|
/azp run Azure Container Networking PR |
|
Azure Pipelines successfully started running 1 pipeline(s). |
QxBytes
approved these changes
May 29, 2026
isaac-dasan
approved these changes
May 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sort epInfos cni/network/network.go) after the createEpInfo loop. In stateless mode, ExternalInterfaces is empty on every ADD so whichever NIC is processed first determines which interface the network gets bound to. If DelegatedVMNIC wins the race, SecondaryEndpointClient moves its interface into the pod namespace, then TransparentEndpointClient fails with "no such network interface".
Reason for Change:
Issue Fixed:
Requirements:
Notes: